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Interactive Conflict Resolution for Personalized Policy-Based Services^ L?£ 



Field of the Invention 



5 The present invention relates in general to Internet telephony and services 

where enterprises and end-users have the capability of personalizing their features, and 
more particularly to detection and resolution of conflicts in telephony services and 
features described using policy-based (scripting) languages such as CPL. 

10 Background of the Invention 

IP (Internet Protocol) and related new forms of applications are now 
incorporating a high degree of personalization. In IP telephony, technologies such as 
CPL (Call Processing Language) are being defined to allow users to specify their own 

15 services and features for controlling the handling of calls. Call processing is currently 
the domain of experts who thoroughly understand the issue of conflicts among 
features. Multiple features may interact in ways that create indeterminate behavior. If 
care is not taken, the addition of a new feature may cause errors in the actions of 
features that had previously worked flawlessly. New features are evaluated extensively 

20 in the design process by experts and tested in conjunction with all other features after 
the design phase in order to prevent undesired interactions from affecting the end user. 

With the advent of personalized features, the reliance on expert designers is no 
longer possible since users are now able to design their own features. In particular, 

25 users who are ordinarily unfamiliar with the issues of formal logic expect features to 
be understood and conflicts to be resolved in ways that they find natural. It is common 
for an executive to tell his/her secretary that no calls should be put through in the 
afternoon and also to tell him/her that if an important customer named Terry March 
calls to put him straight through. What happens if Terry March calls in the afternoon? 

30 It might not be difficult for an ordinary user to identify the conflict if these were the 
only two instructions specified. However, if these were but two of many policies and 
were specified at different times, it might be difficult for a user more concerned with 
other matters to identify the conflict at first glance. 
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Accordingly, there is a need in the art for a mechanism to allow an ordinary 
user to test or validate the overall behavior of all policies that he/she has specified so 
that he/she will understand and approve of all of the interactions among them. Such a 
5 mechanism must be sensitive to how a naive user will tend to specify features and the 
user's expectation that they will be resolved. 

This expectation tends to favor more specific polices over less specific ones. 
This specificity may address time, people or places. Users could, for example, specify 
10 a place such as a particular meeting room and expect it to predominate over a more 
abstract concept such as policies on all meeting rooms. Specific persons may 
predominate over more abstract groups, and more specific times may predominate over 
more abstract time descriptions. 

15 As discussed above, prior art communication services such as the AIN 

(Advanced Intelligent Networks), have been created by expert engineers who have 
relied on two options for detecting and resolving conflicts or undesirable interactions- 

1. At design time (offline): When different services (often created independently) are 
20 integrated into the system, conflicts and their resolution may be undertaken before 

the features are made available to the end-user. Techniques such as testing and 
proofs based on formal models can be applied at the requirements, design, and 
code level to detect interactions, and service precedence or tighter service 
integration can be used to solve them. 

25 

2. At run time (online): When not all conflicts or undesirable interactions can be 
eliminated at design time, service providers can rely on run-time mechanisms that 
monitor the system used by the customer and react dynamically to resolve a 
problem once detected. 

30 

In both of the above cases, the resolution is the same for all users, whatever 
their preferences, intentions, context, or understanding of the services. 



As indicated above, new types of communication/collaboration services and 
applications are emerging, enabled by recent IP telephony protocols and languages 
such as SIP (Session Initiation Protocol) and CPL (Call Processing Language). These 
services benefit from the availability of various sources of contextual information (e.g. 
5 user's location, presence, schedule, relationships, preferences, etc.) to satisfy a wide 
variety of requirements. Such services are easily tailored to different vertical markets 
and are adaptable to changing customer needs and expectations. These services are no 
longer being defined centrally by expert designers, but rather are being defined at the 
edge of the network, by end-users who are not trained in the details of feature design. 

10 

In the personalization context addressed herein, end-users have the capability 
of creating their own services through policies, and are able to define their own 
solutions to resolving conflicts among these policies. Two main situations can be 
distinguished: . 

15 

A. Conflicts among policies of a single user: Such conflicts can be detected at 
design time, when a user inputs policies in the system. Since the system and the user 
have knowledge of all the policies of this user, there is an opportunity of resolving 
conflicts interactively. Moreover, different users have the flexibility to resolve 

20 conflicting policies in different ways, which is not the case in traditional prior art 
systems. 

B. Conflicts among policies of multiple users: Since there can be a large number 
of users, each with their own set of policies, the number of potential conflicts rapidly 

25 becomes unmanageable. Design time detection with interactive resolution is 

inadequate because of the sheer number of conflicts to solve (many of which may 
never occur if two particular users never call each other) and of the need to negotiate a 
resolution among multiple users. Conflicts of this type must therefore be detected at 
run time. US Patent 5,920,618 (Fleischer and Plunkett) entitled Apparatus and Method 

30 for Managing Telephony-Based Services describes such a mechanism for Advanced 
Intelligent Networks (AIN), which uses conflict detection rules described in an expert 
system. US Patent 6,243,697 (Crowther) entitled Detecting Service Interactions in a 
Telecommunications Network, also for AIN, makes use of an expert system where 



interaction rules check services' data parameters for detecting~interactions. Conflict 
resolution can be conventional (resolution mechanisms embedded in the system to 
provide the same resolution for all users), based on fuzzy logic (e.g. Amer, M., 
Karmouch, A., Gray, T. and Mankovskii, S. Feature Interaction Resolution Using 
5 Fuzzy Policies, in Proceedings of the 6th Feature Interactions in Telecommunications 
and Software Systems, pp. 94-1 12, Amsterdam, Netherlands, May 2000. IOS Press), or 
interactive (e.g. while using the service, the user is prompted when a conflict is 
detected). 

10 Although several solutions exist for items 1 , 2, and B above, there is currently 

no solution proposed for A where a user creates several individual policies. New 
languages for telecommunication systems such as IETF's Call Processing Language 
(CPL) support policies, but CPL assumes an outside mechanism for detecting 
interactions at design time (it has no mechanism on its own). CPL triggers a feature 

15 when all pre-conditions are met and so uses a totally-ordered priority system for 
resolution. 

More particularly, CPL bundles operations for incoming and outgoing calls 
into two independent decision trees. Since the fea ture preconditions are ordered, these 
20 trees provide an absolute ordering of priorities among the features. This creates the 

desirable condition of no possibility of indeterminacy among pre-conditions. However 
this comes at the expense of requiring the user to create this absolute ordering. 

The totally-ordered priority system of CPL is sufficient in an execution 
25 environment, but is inadequate in a design environment because individual policies no 
longer exist and hence their management becomes next to impossible. A small change 
to one individual policy can require a complete restructuring of the CPL script that 
integrates all of a user's individual policies. However, enabling users to define 
individual policies may lead to undesirable interactions such as loops and shadowing. 



30 



Shadowing may be described as an overlap in feature pre-conditions. One 
policy may become unreachable and never executed because calls that meet its 
preconditions are handled by the shadowing policy. So, for example, a policy that 



Q 



forwards all calls that arrivefrom 2700 pm to 4700 pm to voice mai 1 wuFdlfia'dowa" 
policy where all calls from John Doe from 2:30 pm to 3:00 pm should be forwarded 
directly to the user. In order for the policies to operate properly, an understanding of 
the common intentions of human users must be developed, as discussed in greater 
detail below. 



Policy conflict detection is present in various domains, principally in the field 
of network management. Much of the existing work is based on concepts developed by 
Sloman and Moffett (see Moffett, J. D. and Sloman, M. S. Policy Conflict Analysis in 

10 Distributed System, in Journal of Organizational Computing, pp. 1-22, 1994). In 
particular, Thebaut et al. {Policy management and conflict resolution in computer 
networks, US Patent 5,889,953, March 30, 1999) have embedded in their system 
conflict resolution rules that are triggered at run time. Ahlstrom et al. {Recognizing and 
processing conflicts in network management policies. US Patent 6,327,618, December 

15 4, 2001) provide detection and interactive resolution in their system based on simple 
policies, but without addressing proper needs of complex communication systems (rich 
policy language and resolution mechanisms other than plain precedence) and usability 
concerns (suggestions, hiding the policy language, etc.). Fu et al. tailored Sloman 5 s 
work to detect and solve IPSec policy conflicts, at run-time, while trying to comply 

20 with security requirements (see Fu, Z., Wu, S. F., Huang, H., Loh, K., and Gong, F. 
IPSec/VPN Security Policy: Correctness, Conflict Detection and Resolution. IEEE 
Policy 2001 Workshop, January 2001). 

Other fields of application also benefit from the use of policy-based systems, 
25 such as set forth in Slaikeu {System for the analysis of organizational conflicts, US 
Patent Application 20010007106, July 5, 2001) who uses policies and 
detection/resolution (based on an expert system) for organizational conflicts. 

In conclusion, none of the foregoing prior art methods are well adapted to solve 
30 the particular problem expressed in A), above. Techniques developed for network 
management are not well-tailored to personalized communication services, features, 
and applications. Moreover, techniques developed for AIN are not suitable for use in 
IP systems where services are created at the edge of the network. 
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Summary of the Invention 

According to the present invention, a method and apparatus are set forth for 
5 defining feature policies and handling the specific stages of this definition. In general, 
the process includes: 

1. Entering user policies described in a straightforward manner (e.g. using a Web 
browser and user-understandable language) in such a way that they can be 
. io translated into a formal executable language. 



2. Translating this user-understandable language into an executable feature 



language such as the IETF's CPL. 



3. Either compelling or providing the user with an option to validate the overall 
feature set before it is are uploaded to the execution system. 



15 



4. If validation is selected, translating the features from CPL into another format, 
such as FIAT, from which it is possible to detect common feature specification 



errors. 



20 



5. Take the FIAT detected errors and analyze them in a manner that is aware of 
the expectations and common errors of n ai ve users. Interpret the FIAT 
determined possible errors as errors that are common to naive users. 



6. Report these errors to the user (e.g. via the Web interface) in terms that are 
understandable to naive users and compatible with how the policies were 
originally described. 



25 



7. Provide the user with options to either accept the interactions as they are, repair 
them manually or to accept a recommend ation of an automatic correction. 
Unlike conventional systems, where feature interactions are solved in the same 
way for all users, the selected resolution is personalized in the present 
invention to satisfy the end-user's intentions, independently of how others solve 



similar conflicts. 



30 



8. Upload the features to the execution system. 



The present invention relates to the overall process and all of the above steps 
except for the processes in FIAT error detection. In particular the translation of CPL 



into a FIAT representation and the analysis of the FIAT results in terms of naive user 
errors and expectations form part of the present invention whereas the operations 
specific to FIAT itself form part of the prior art. 



5 Brief Description of the Drawings 

The invention will be better understood with reference to the drawing, and 
following description, in which: 

10 Fig. 1 is a Use Case Map showing policy execution on call control, as is known 

in the art; and 

Figure 2 is a Use Case Map showing policy management, conflict detection, 
and conflict resolution according to the present invention. 

15 

Detailed Description of Preferred Embodiments 

Before turning to a detailed description of an embodiment of the present 
invention, a brief description is provided of the main background concepts used to 
20 implement the invention. These background concepts are publicly known and, as such, 
do not form part of the invention. 

Call Processing Language (CPL) 

The Internet Engineering Task Force (IETF) has standardized a protocol- 
25 independent Call Processing Language (CPL) for Internet telephony services (see 
Lennox, J. and Schulzrinne, H. CPL: A Language for User Control of Internet 
Telephony Services. IETF Internet Draft, January 15, 2002). CPL uses the extensible 
Markup Language (XML) to describe personalized services in terms of policies 
applicable to incoming calls and outgoing calls (see Bray, T., Paoli, J. and Sperberg- 
30 McQueen, C. M. Extensible markup language (XML) L0 (second edition), W3C 

Recommendation REC-xml-20001006, World Wide Web Consortium (W3C), October 
2000). CPL is powerful enough to describe a large number of services and features, but 
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it has imposed limits so that it can run safely inTnternet telephony servers to prevent 
users from doing anything more complex (and dangerous) than describing Internet 
telephony services. The language is not Turing- complete, and provides no mechanism 
for writing loops or recursive scripts. 

5 

CPL scripts can be created by end-users to proxy, redirect, or reject/block calls. 
Policies for one user are combined into a single CPL script and expressed as a decision 
tree where the conditions are based on different types of switches (based on addresses, 
call priority, time, language and any string). There are potentially two decision trees: 

10 one for incoming calls and one for outgoing calls. Sub-actions can be defined to 

improve consistency and reusability. Time conditions, expressed using Time switches, 
are based closely on the specification of recurring intervals of time in the Internet 
Calendaring and Scheduling Core Object Specification (iCalendar COS, as set forth in 
Dawson, F. and Stenerson, D. Internet calendaring and scheduling core object 

15 specification (iCalendar), Request for Comments 2445, Internet Engineering Task 
Force, November 1998). 

Policy-Based Call Control 

20 Call control engines in present day (IP) PBXs, switches, gateways, and proxy 

servers have been designed to make use of policies to implement, control or restrict 
various types of communication services. In this sense, policies are executed by the 
call control engine. Figure 1 depicts a Use Case Map for the simple situation of policy 
execution in call control. In the Use Case Map (UCM) notation, the scenario starts 

25 with a filled circle (triggering event), progresses along a path (superimposed on entities 
and components), and terminates with a bar (result). Such scenarios are independent 
from the types of messages exchanged between the components. 

In the scenario of Figure 1, a conventional call control engine 1 queries its 
30 policy agent 3 upon the reception or sending of a communication by a user (e.g. a 
telephone call). The policy agent 3 accesses and executes the relevant policies 5 
(described as CPL scripts or in another representation) in response to which the call 
control 1 handles the communication (e.g. redirects the call, blocks the call, logs the 



call, etc.). The protocol used between the call control engine 1 and the policy agent 3 is 
well known and therefore not further described herein (e.g. SEP, H.323 or proprietary 
signaling protocols such as MiNet can be used). 



5 Feature Interaction Analysis Tool (FIAT) 

In a recent thesis, Gorse provides a logic representation of communication 
features and a tool (FIAT) for "filtering" (i.e. detecting) incoherences among these 
features, at the requirements level (see Gorse, N. The Feature Interaction Problem: 
1 0 Automatic Filtering of Incoherences & Generation of Validation Test Suites at the 
Design Stage. M.Sc. thesis, SITE, University of Ottawa, Canada, September 2000). 
Although it was not the author's initial intent, the FIAT tool can be used in the context 
of personalized communication policies to detect policy conflicts. 

15 In FIAT (Feature Interaction Analysis Tool), features are described using a 

four-part tuple having a Prolog-based syntax, as follows: 

• Preconditions: mandatory conditions or system states under which the feature 
is activated (e.g. this policy is active from Monday through Friday only). 

• Triggering events: action(s) triggering the feature (e.g. there'is an incoming 
20 call). 

• Results: represent the actions produced by execution of the feature and the state 
of the system after such execution (e.g. forward the call to the voice mail 
system). 

• Constraints: restrictions relative to the variables used in the preconditions, 

25 triggering events, and results describing the feature (e.g. originator is different 

from terminator). 

The vocabulary used for the conditions and actions is not pre-determined and is 
hence very flexible. A feature description also specifies which user is concerned (i.e. 
30 influenced) by the feature (usually the subscriber or the user targeted by a redirection 
or blocking functionality). Additionally, contradictions can be defined explicitly 
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between user-defined terms. For instance, busy (A) can be defined as being in 
contradiction with idle(A). 

The Feature Interaction Analysis Tool (FIAT) is a Prolog program that uses 
5 feature descriptions as inputs and uses filtering rules to detect incoherences, which are 
then reported as outputs. Six filtering rules are currently part of the tool, but others can 
easily be added. 

• Dl : Two features from the same user are triggered by the same events and yield 
different but not contradictory results. 

10 • D2: Two features from the same user are triggered by the same events and yield 

contradictory results. 

• D3: Two users subscribe to two different features that concern the same user. 
These features are triggered by the same events and yield different but not 
contradictory results. 

15 • D4: Two users subscribe to two different features that concern the same user. 

These features are triggered by the same events and yield contradictory results. 

• Tl : The results of a feature trigger another feature description and results of 
both descriptions present a contradiction (transitive incoherence). 

• T2: the results of a feature trigger another description and vice-versa (loop 
20 , incoherence) 

These rules are implemented in Prolog, and the tool makes extensive use of 
Prolog's backtracking and unification mechanisms to ensure that potential 
incoherences are indeed detected. 



25 



For each incoherence detected, FIAT generates an example of a specific 
situation or scenario that would lead to an undesirable interaction. These scenarios can 
be used as user information to better illustrate a problem, or be converted to test cases, 
which are reported as text-based output. 



30 
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Finally, FIAT supports a database of previously found incoherences. This 
database can be used to report only new incoherences (e.g. when a new feature is 
added). 



5 As discussed briefly above, the current techniques used for managing policy- 

based communications suffer from several limitations. Policy languages such as FIAT 
or CPL are not easily usable by common end-users as they are closer to logic and 
programming languages than to natural language. Even though usability was one of 
CPL's goals and even though policies in general can be scripted manually (e.g. in 

10 XML), this usually requires an expertise level that most end-users do not have or are 
not willing to learn. The policy descriptions should therefore be hidden behind a usable 
interface tailored to the work environment of the end-user. Web and voice interfaces 
are nowadays commonly used both by enterprise workers and by individuals at home, 
and policies can be managed through such interfaces to create, modify, delete, activate, 

15 deactivate, and prioritize policies. 



It is important to distinguish between policies used to describe individual 
services and those that are meant for execution. To go from the first to the second 
requires integrating the policies in some way. Because of a more focused scope, 

20 individual services are easier to create, understand, select and maintain. CPL is good at 
describing integrated communication policies as two decision trees (for incoming and 
outgoing calls), and this is suitable for execution by policy agents. However, 
describing the integration directly becomes rapidly more error-prone and difficult to 
manage for the user than keeping individual policies separate. A simple modification 

25 to one individual policy may require a complete restructuring of the integrated CPL 
tree. Therefore, there is a need to go from user-suitable individual policies to an 
execution-suitable integrated version of these policies. 

Conflict detection among policy-based communication services is difficult with 
30 existing concepts. Firstly, CPL does not offer any support for conflict detection 

because the selection of a branch in a script's decision tree is always deterministic. The 
first condition of a switch that is satisfied is selected, and the presence of other 
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satisfied conditions in the same switch is not seen as problematic even though this 
could be a symptom of script that incorrectly supports the user's intentions. The burden 
is on the user to integrate his/her individual policies to obtain a resulting behaviour 
that satisfies his/her original intentions. Keeping the original policies separate with a 
5 loose integration (initially) and resolving conflicts interactively can guide the 
generation of the desired integration. Also, FIAT's language was meant for user- 
defined features, rather than for policies. A mechanism to convert policies in general 
(and CPL in particular) to FIAT's language is necessary to enable the usage of FIAT's 
filtering rules (which become policy conflict detection rules). 

10 

Like many other feature interaction detection tools, FIAT describes the 
detected incoherences (conflicts) as well as examples of problematic scenarios. 
However, such tools usually have two limitations. FIAT and similar tools do not report 
the conflicts detected in the user-level (natural) language used to define the policies 

15 involved. They usually report them in terms of the formal representation of the 
policies, thereby requiring a conversion from that formal representation to the 
language used in the original (Web-based) policy management system. FIAT and 
similar tools also do not provide suggestions on how to resolve the conflicts detected. 
These suggestions need to be adapted to the nature of the policies involved as well as 

20 the type of conflict. 

Once conflicts are reported, they can be solved by the end-user, but there are 
several limitations. Conventional approaches often implement one resolution 
mechanism (at design time or at run time) for all users, but this is not acceptable in a 
25 context where users have the opportunity to create their own services. Resolution 

mechanisms must be allowed to vary from user to user. Suggesting solutions is only 
half of the problem. These solutions need to be supported by highly usable means to 
implement them (e.g. a simple click of a mouse for interactive resolution). The prior 
art does not address this issue. 



Turning to Figure 2, the policy-based call control introduced with the UCM of 
Figure 1 is supplemented by providing a policy m anagement system 6 for supporting 
policy management, conflict detection, and conflict resolution. 
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A policy management interface is presented to the end-user through a Web 
Browser running on a Web server 7 (e.g. Netscape, Internet Explorer, Opera, etc.). 
Although a Web server 7 is shown, for description purposes, it will be understood that 
5 browsers are available for use on various devices, including personal computers, 

Personal Digital Assistants 9 (PDAs), wired phones with large screens 1 1 (e.g. Mitel 
5140 Webset), and cellular phones, etc. Accordingly, access to the policy management 
system 6 is somewhat device independent. 

10 Web-based policy management enables the creation, modification, deletion, 

activation, deactivation, and prioritization of policies. Web-based interfaces are easily 
adaptable to any home or work environment (e.g., hospitality, medical, engineering, 
legal, etc.) and can communicate with the end users using a language and a 
terminology with which they are familiar. Policies can hence be described interactively 

15 in those terms, and translated to a particular representation (e.g. CPL) by a conversion 
application running on the Web server 7, as shown by the Manage Policies UCM in 
Figure 2. Thus, CPL can be entirely hidden from the end-users, thereby achieving one 
of the objectives set forth above. 

20 The Web-based interface represents individual policies internally (e.g. in 

proprietary ASCII format or in a database, or using a standard representation such as 
CPL). The same interface is also capable of synthesizing a single script (e.g. in CPL) 
that integrates all the activated policies that belong to a user. This integrated script is 
used at run time by the policy-based call control engine 1 (as shown by the Execute 

25 Policies UCM in Figure 2). 

Similarly, although the scenarios illustrated herein focus on Web-based 
interfaces, a voice-activated interface maybe used to provide audio menus and speech- 
recognition capabilities for enabling a user to manage policies through their phone 
30 (wired or wireless). 

The Validate Policies UCM in Figure 2, adds policy conflict detection 
functionality to the policy management system 6 such that upon a simple request (e.g. 
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user click of a validate button), the system detects potential issues m the user's list of 
activated policies. To enable this, the policies are converted to a formal representation 
suitable for analysis, such as FIAT rules. Once translated, individual policies are 
processed by the FIAT tool, which reports various types of conflicts and counter- 
5 examples as described briefly above. Since the report describes conflicts in terms of 
FIAT rules that are unsuitable for the user, the reported conflicts are converted to 
HTML code for presentation in the Web-based policy management interface via Web 
server 7. 

10 In addition to conflict reporting, suggestions on how to resolve these conflicts 

are generated and reported. These suggestions (edit, disable, reprioritize, add an 
exception, or tolerate) are tailored to the particular type of conflict and to the policies 
involved, and are presented to the user in a menu or as hyperlinks in the policy 
management interface. Selecting one of them (e.g. via the Correct Policies UCM in 

15 Figure 2) activates the proper sequence of requests to the application on the Web 
server 7 to fix the problem according to the option chosen. The individual and 
integrated policies are then regenerated. It will be noted that this resolution is local to 
the user and in no way affects how other users may resolve their own policy conflicts. 

20 The system of Figure 2 provides an overall mechanism for the creation, 

management, testing and provisioning of policies. Through the Web interface (with 
text or voice browser) a user may enter a policy in a user friendly and intuitive way. 
This may be done by filling in structured sentences or by filling in forms, via a Web 
interface tailored to the particular environment of the user (hospital, law firm, store, 

25 school, home, etc.). The system of the invention provides structured information that 
may be converted into a formal representation (e.g. CPL or FIAT). 

The user may then request that the multiple policies be tested for undesirable 
interactions in response to which a report is returned to the user indicating any and all 
30 interactions detected. Options are presented to the user for either manually correcting 
the features and their relative priorities or following a machine-developed 
recommendation for automatic correction. When the user is satisfied that no 
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undesirablelnteractions remain7fie7she may have them transmitted to the policy server 
3 for operation. 

The Web interface enables a user to manage his/her list of policies (e.g. in a list 
5 box or in a different panel or frame), typically sorted by name or by priority. The 
following operations on policies are supported (via buttons, links, menus, or voice 
activation): 

Create: Create a new policy, add it to the list, and activate it. 
Modify: Modify the selected policy. 
Delete: Delete the selected policy from the list 

Duplicate: Make a copy of the selected policy (with the intention of modifying 
it later). 

Deactivate: Deactivate the selected policy. Policies that are inactive are still 
kept on the list but are marked as such (e.g. different color or shadowed text). 
They are not used for validation or execution, but they are kept for future 
activation. 

Activate: Activate the selected inactive policy. 

Set Priority: Set the priority of the selected policy, which can be an absolute 
priority or a relative one (e.g. move the policy higher or lower in the list when 
sorted by priorities). 

Validate: Detect and report conflicts in the list of active policies. 
Approve: Approve the current list of policies and enable them for execution 
(e.g. through the generation of a single CPL script uploaded to the call control 
switch 1 or to the policy agent 3). 

Policies can be created using structured text, obtained in various ways (free 
form, lists, pop-up menus, etc.) from the user. A policy contains seven main elements: , 

30 • A name, used as unique identifier. 

• A priority, expressed as a numerical value. 



10 
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20 
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• The operation T v/hich is typically either forward an incoming call, block an 

incoming call, or block an outgoing call 

• A precondition, based on the characteri stics of the caller or callee (e.g. phone 
number, role, domain, location, organization/business, name, device, presence 

5 information, etc.). Many characteristics can be combined in a logical 

expression. 

• The operation target, typically a phone number, a person, a role, a device, 
voice mail, etc. 

• An optional list of exceptions to a general precondition, based on the same 
10 types of characteristics. 

• A time constraint, where the policy is active. This can be a specific time 
interval (e.g. from 1:00 to 2:00) or recurring intervals (e.g. every Tuesdays). 
"Forever" can be used to specify the absence of time constraint. 

15 A policy is general when the precondition is a domain of values (e.g. all calls, 

all calls from Canada, all calls from Mitel). If the precondition relates to particular 
values, then the policy is specialized. A genera] policy may contain exceptions, which 
are typically particular values (often in the same domain as the one used in the 
precondition, but not necessarily). 

20 

For example, consider the following general policy: 
Mitel_To_Pager (2): 

Forward calls from Mitel to Mv Pager except if the call is from Terry March from 09:00 on 
25 Sunday. November 24. 2002 to 10:00 on Friday. November 29. 2002 . 

• The policy name is Mitel_To_Pager and the priority is 2; 

• The operation is the forwarding of an incoming call, and its target is My Pager; 

• The precondition is all calls from Mitel, with the exception of Terry March; 
30 • The time constraint is from 9:00 on 2002/1 1/24 to 10:00 on 2002/1 1/29. 



On the Web interface, various elements can be hyperlinked to the form where 
they have been defined (e.g. the underlined elements in the example MitelJToJPager 
policy). 
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As discussed above, individual policies created by end-users are either 
specialized (e.g. how to process calls from a specific individual) or general (e.g. how 
to process all incoming calls) with an optional list of exceptions. In both cases, 
5 individual policies are translated into CPL specifications that consist of a single branch 
(instead of the usual decision tree). Rather than bundling all features into a single tree 
with implicit priorities, individual features are described as individual trees with 
explicit priorities among them. Prioritization of the policies is achieved through 
numerically naming the CPL scripts. Besides priority between policies, a priority also 
10 applies between the exceptions and the general case. For operation, this structure may 
be retained and the features executed by a system that is aware of the single trees and 
individual priorities. Alternatively, the features can be executed on a standard CPL- 
enabled system, by connecting the features together using CPL OTHERWISE 
statements in descending order of priority to create a standard CPL feature tree. 

15 

The translation of specialized policies into FIAT rules is straightforward: the 
single branch is visited downward, collecting the condition (e.g. time, caller, 
domain...), the trigger (e.g. incoming call parameters) and the result (e.g. redirect, 
location). This information is then used to produce the corresponding FIAT rule, using 
20 the following mapping: 







Name 


Rule name 


Priority 


Rule number 


Operation 


Rule result 


Precondition 


Rule triggering event 


Target 


Rule result 


Exceptions 


Rule constraint 


Time constraints 


Rule precondition 



Consider the following example of a policy (with name Conference and priority 
1) that redirects incoming calls from Reception to My Pager (available at the address 
25 terry_march@pager.ottawahospital.com) during a conference in November: 

Forward calls from Reception to Mv Pager (no exceptions) from 09:00 on Sunday, 
November 24, 2002 to 10:00 on Friday. November 29. 2002 . 

30 The CPL script generated from this policy and called Conference _/ is the following: 
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<cpl> 

< incoming > 

<time-switch> 

5 <time dtstart= ,f 20021124T090000" dtend=" 20021129T100000 " > 

< address -switch> 

<address contains="Reception" > 

<location url="sip : terry_march@pager . ottawahospital . com"> 
<proxy/> 

10 </location> 

</address> 
</address-switch> . 
< / 1 ime > 
</time-switch> 
15 </ incoming > 

</cpl> 

The translation of the CPL script into FIAT becomes: 

20 feature ([ 'Conference ' , 1] , 

[subs (user, Any) ,time{ [dtstart (d (2 002 , 11 , 24 , 9 , 0 , 0) ) , dtend (d (2002 , 11 , 29 , 10 , 0 , 0) ) , 

interval ( ' 1 ■ ) , wkst ( 1 MO ')])], 
[incoming ( [address (contains ( ■ Reception' ))])], 
25 [proxy ( [location ( ' sip : terry_march@pager . ottawahospital . com ')])]) : - 

true . 

In the previous FIAT rule: 

- ['Conference 1 , 1] is the rule identifier \ with the rule priority. 

30 - [subs(...) 3 time(...)] is the rule precondition corresponding to the policy time 

constraint, if any. The subs part, required by FIAT, is not used in the 
mapping. 

- [incoming(...)] is the rule triggering event, corresponding to the policy 
precondition. 

35 - [proxy(...)] is the rule result, corresponding to the policy operation and its 

target. 

- true is the rule constraint. It is set to tine for specialized policies (no 
constraint), but it is used to represent exceptions in general rules. 

40 A general policy that contains exceptions generates a separate CPL 

specification for the general case, and one for each exception (as opposed to being 
combined into a single CPL script using the otherwise construct). The exceptions bear 
a higher priority than the general case, and this is reflected by the numerical naming 
scheme discussed above. 



45 



The set of CPL scripts that constitute a general policy are translated one at a 
time. While the translation of the first script is identical to the translation of 
specialized policies, the translation of the subsequent parts of that policy varies: they 



±2. 
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are further refined by adding the negation of the conditions of all previously translated 
parts. This process can be depicted as: 

previous_conditions = empty ; 
5 foreach part in (list_of_CPL_parts) 

collect {conditions, triggers, results} from part 

produce_FI AT (conditions and not (previous_condit ions) , triggers, results) 
previous_conditions = previous__conditions + conditions 

10 For example, the following is a policy that forwards all incoming calls to Jim 

Darling, unless the call originates from Reception: 

Forward any call to Jim Darling except if the call is from Reception forever . 
15 The CPL scripts generated from this policy are the following: 

<cpl> 

< incoming > 

< addr e s s - s wi t ch> 
20 <address contains=" Reception" > 

</address> 
</address-switch> 
</ incoming > 
</cpl> 
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and 



<cpl> 

< incoming > 

30 < location url = " sip : j im_darling@ottawahospital . com" > 

<redirect /> 
</location> 
</ incoming > 
</cpl> 

35 

It will be noted that the absence of specific actions to be taken in the first CPL 
script results in the default behaviour of the system, namely to accept the incoming 
call. 

40 The translation of the foregoing CPL scripts into FIAT becomes, respectively: 

feature ( [ 1 Any_but_Reception' , 3] , 
[subs (user, _G728)], 

[incoming ( [address (contains ( 1 Reception '))])], 
45 tdefaultAction] ) 

true . 

and 

50 feature ( { ' Any_but_Recept ion * , 4 ] , 

[subs (user, _G834)], 
[incoming (ANY) ] , 

[redirect ( [location( ' sip : j im_darling@ottawahospital . com ' ) ] ) ] ) : - 
ANY \= [address (contains (' Reception' )) ] 
55 | ANY = anyUser. 
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As discussed above, all CPL scripts are assigned a priority. This priority is 
preserved within the FIAT rules such that later interpretation of the importance of the 
incoherence detected may be qualified. The lowest numerical value is associated with 
the highest priority (herein given to the exception rule). 

5 

Time constraints, specified with semantic s close to that of the iCalendar 
standard, may represent unique occurrences as well as recurring intervals. To cope 
with this particularity, the set of FIAT rules also specifies that any two rules for which 
time does not overlap are rules in contradiction, and therefore should not be pair-wise 
10 analyzed for incoherences. For example, given that one rule applies to Mondays and 
another to Tuesdays, their time specifications do not overlap; this non-overlapping 
characteristics is seen by FIAT as a contradiction and no further analysis is carried on 
that pair of rules. 

15 For any pair of time specifications, an overlapping interval may be sought as: 

intervalFound = timeLimit Reached = false 
repeat until intervalFound or time Limit Re ached 

if ( 1 ower Boundary (timeSpecl) isWithin boundariesOf TimeSpec2 or 
20 upper Boundary (timeSpecl) isWithin boundariesOf TimeSpec2 or 

lowerBoundary (timeSpec2) isWithin boundariesOf TimeSpecl or 
upperBoundary (timeSpec2) isWithin boundariesOf TimeSpecl) then 
intervalFound = true 
endif 

25 if timeSpecl startBefore timeSpec2 then 

timeSpecl = next Interval (timeSpecl ) 
else 

timeSpec2 = next Interval (timeSpec 2 ) 
endif 

30 if upperBoundary (timeSpecl) > timeLimit or upperBoundary (timeSpec 2) > timeLimit 

then 

timeLimitReached = true 
endif 

35 The timeLimit selected should reflect the life expectancy of the rule (e.g. a 

year). The search for an interval should also cease when a nextlnterval cannot be 
computed (e.g. such is the case for a time specification that applies to a unique event 
like a conference). 

40 For a system in which a standard CPL script integrating multiple 

features/policies is provided (e.g. generated manually or by other means), the system of 
the present invention extracts individual CPL scripts with priorities for processing by 
the system as set forth below. 
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CPL specifications are totally ordered. Hence, in a strict sense, there can be no 
conflicting instructions, or interactions. The burden of establishing this total ordering 
is carried by the user. 

5 The general structure of a CPL specification is a decision tree. At some point, 

an element of decision is elected (e.g. caller): either the condition is verified, the 
condition is not verified, or the element of decision is not present. In each case, a 
corresponding sub-tree follows with further instructions. Eventually, each branch 
develops, not into sub-trees, but rather into a leaf that consists of an action to be 
10 performed (e.g. redirect, reject). 

To permit coherence analysis, the tree of call processing instructions of the 
CPL specification is flattened into a FIAT description. That is, once for the tree of 
incoming calls, and once for the tree of outgoing calls. Starting at the top, the tree is 

15 visited while collecting conditions and triggers defined in the elements of decision of 
the nested sub-trees. Both conditions and triggers are contextual pieces of information 
that can semantically be put in a single set. But, for the sake of interpretability and 
user-friendliness, contextual information is collected as conditions (e.g. time) while 
triggers are based on acute and connection-oriented facts (e.g. who is calling). Actions 

20 to be performed (e.g. redirect) are collected as results. 

When the visit of a tree reaches a leaf (i.e. an action to be performed), the 
conditions, triggers and results collected thus far are output as a FIAT rule. The visit 
continues by returning to the closest upward decision point with an unvisited branch, 
25 resetting the collection of conditions, triggers and results as they were at that point, and 
carrying on with the visit of the yet unvisited branch (this is called a depth-first 
traversal). If the branch is an "otherwise", the corresponding condition is negated; if 
the branch is a "not-present", the corresponding condition is removed. Then, the visit 
of the tree is resumed. 
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As FIAT rules are produced, they are assigned a priority such that later analysis 
may provide more precise information on the incoherences based on the ordering used 
in the CPL specification. 
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The incoherences reported by FIAT contain information identifying the 
features, their priorities, and the incoherence itself. The first step toward the 
interpretation of the incoherence consists in determining the type of policy, namely 
5 whether they are general or specialized. In some cases, further understanding of the 
problem is obtained by comparing the relative priorities of the policies. Then, the 
problem is reported to the user. This reporting starts by identifying the category of 
incoherence, the role of each policy in the problem is exposed, an example of the 
possible misbehaviour resulting from the presence of the two policies is given and, 
10 when applicable, one or many ways to correct the situation are proposed. 



The following types of problems are reported to the user: 

0. Redundancy: Two general policies are active. A special case is Conflict with 
15 Redundancy, where a general policy and an exception for the other general 

policy lead to different resulting actions. 

1 . Shadowing: A general policy (i.e. that applies to all members of a user-defined 
domain, but potentially with exceptions) overrides a specific policy (that 
applies to an enumeration of one or many individuals). The specific policy can 

20 never be triggered. 

2. Specialization: Notifies that a specific policy will be selected over a general 
policy of lower priority. 

3. Conflict: Two policies address the same situation (their preconditions overlap) 
but with different resulting actions. 

25 

The following types of suggestions can be provided by the system: 

a. Edit a policy (enables the user to modify one of the conflicting policies). 

b. Disable a policy (deactivate a policy, without deleting it). 

c. Set the priority of a first policy above/below the priority of a second policy. 
30 d. Add an exception to a general rule. 

e. Tolerate the conflict and no longer report it (leave it to the system to decide). 
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The comments explaining the conflicts have hyperlinks to the policies 
involved, hence they can at any time be edited (suggestion a, above). Also, each 
detected conflict, whatever its nature, can be tolerated and put in a database so it will 
no longer be reported (suggestion e, above). 

The other types of suggestions (b, c, d) are adapted to the particular conflict 
detected, and only the relevant suggestions are offered: 







Redundancy 


• Add (duplicate) exception to general 
policy 

and 

• Disable first general policy 

• Disable second general policy 


Shadowing 


• Set priority of specialized policy 
above that of general policy 

• Set priority of general policy below 
that of specialized policy 

• Disable general policy 

9 Disable specialized policy 


Specialization 


• Notice/warning (no suggestion) 


Conflict 


• Disable first policy 

• Disable second policy 



10 To facilitate and accelerate the correction of the policies, the suggestions 

proposed to the users are hyper-linked to commands and parameters that instruct the 
system to apply the one selected (e.g. clicked on), as discussed in greater detail below. 
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Each incoherence detected by FIAT can be interpreted according to the 
following procedure: 



20 



25 



30 



where: 



foreach incoherence in (list_of _incoherences) { 

where incoherence = (Featurel, Feature2 , problem) 

determineCategory ( incoherence , Category) 

if priority (Featurel) > priority (Feature2 ) then 

swapNumbersOf Features (incoherence) 
endif 

reportConf lict { incoherence , Category) 

} ... 



% Tuple structure 

% to report on shadowing 



determineCategory (incoherence, Category) :- 

where incoherence = (Featurel, Feature2 , problem) % Tuple structure 

if generalPolicy (Featurel) then % Featurel is general 

if generalPolicy (Feature2) then % Feature2 is general 

Category =0 % REDUNDANCY + CONFLICT? 

else * Feature2 is specialized 

if priority (Featurel) > priority (Feature2) then 
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g^ tegory - ± %~SHAD0WING 
else 

Category =2 % EXCEPTION/ SPECIALIZATION 

endif 

5 endif 

else ' % Featurel is specialized 

if generalPolicy <Feature2) % Feature2 is general 

if priority (Featurel) < priority (Feature2 ) then 

Category = 1 % SHADOWING 

10 else 

Category =2 % EXCEPTION/ SPECIALIZATION 

endif 

else % Feature2 is specialized 

Category =3 % CONFLICT 

15 endif 
endif 

and: 

report Conflict (Incoherence, Category) :- 
20 case Category of 

0: if generalTrigger (problem) then 

"Redundancy: both policies provide directives for all incoming calls" 
else 

"Conflict: exceptions collide" 
25 endif 

1 : " Shadowing : general policy Featurel overrides policy Feature2" 
2 : "Specialization: policy Featuresl specializes general policy Feature2" 
3 : "Conflict : both policies address the same condition" 
endcase 

30 

Using such a procedure, HTML code can be produced to format the report and 
provide appropriate hyperlinks to the user, via the original interface used to generate 
the policies (e.g. Web browser). 

35 Example 

As an example of conflict reporting with su ggestions, consider the following 
set of four policies (prioritized as they appear), wherein words underlined are 
hyperlinks to definitions (in policies and conflicts) or to correction procedures (in 
40 suggestions): 

Conference: 

Forward calls from Reception to My Paqer (no exceptions) from 09:00 on Sunday. November 
24. 2002 to 10:00 on Friday. November 29, 2002 . 
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Working From Home: 

Forward any call to My Home Phone (no exceptions) forever . 



Any_but_Reception: 

50 Forward any call to Jim Darling except if the call is from Reception forever . 

Appointment: 

Forward calls from Reception to My Paqer (no exceptions) from 08:00 on Thursday. November 
28. 2002 to 17:00 on Monday, December 02. 2002 . 



Some of the problems uncovered by FIAT and interpreted by the above 
algorithm include: 
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Specialization 

The Policy Conference specializes the general policy Working From Home . 

5 When a call comes in from 'Reception ' , it will be forwarded to location 

'sip. terry _march@pager. ottawahospital. com 1 by policy Conference, instead of being 
forwarded to location , sip:terry_march@home.ottawahospitalcom t by the general 
policy Working From Home . 

10 The system therefore generates a notice: 



Suggestion: 

• TOLERATE this conflict 

15 Conflict 

Both policies Conference and Any but Reception address the situation where 
a call comes in from 'Reception' y but they react differently. 

Since the policy Conference has priority over policy Any but Reception , the 
20 call will be forwarded to location 'sip: terry _march@pager. ottawahospital. com' 
(instead of being [defaultAction].) 

Suggestions: 

• if the currently prioritized policy is preferred, DISABLE policy 
25 AnybutJReception 

• else, if the alternative is preferred, DISABLE policy Conference 

• TOLERATE this conflict 
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Conflict within Redundancy 

The general policies Working From Home and Any but Reception specify 
conflicting actions to be taken when a call comes in from 'Reception' . 
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The call will be forwarded to location 
f sip:terry_march@home.ottawahospital com' since Working From Home has higher 
priority, while policy Any but Reception would have let it through. 

5 Suggestions: 

see the related Redundancy warning, below, for details. 

Redundancy 

The general policies Working From Hom e and Any but Reception both 
10 provide directives for all incoming calls. 

The policy Working From Home has higher priority and will have calls 
forwarded to location 'sip: terry jnarch@home.ottawahospital.com'. Policy 
Any but Reception will never have calls forwarded to location 
1 5 'sip:jimjdarling@ottawahospital. com '. 

Suggestions: 

• if the current priority is preferred, 

• ADD EXCEPTION for Reception to policy WorkingJFrom_Home 
20 • DISABLE policy Any_but_Reception 

• if the alternative is preferred, 

• DISABLE policy Working_From_Home 

• TOLERATE this conflict 

25 Shadowing 

The general policy Working From Home overrides policy Appointment . 

When a call comes in from 'Reception ' , it will be forwarded to location 
'sip: terry_march@home.ottawahospital.com ' by policy Working From Home instead 
30 of being forwarded to location 'sip:terry_march@pager. ottawahospital. com ' by policy 
Appointment . 
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Suggestions: 

e SET PRIORITY of Appointment above that of Working_From_Home 

• SET PRIORITY of Working JFromJHome below that of Appointment 

• DISABLE policy WorkingJFrom_Home 
5 • DISABLE policy Appointment 

• TOLERATE this conflict 

Various levels of sensitivity for the detection of conflicts can be defined by the 
user, in a way similar to compiler options where one can choose the types of warning 
10 to be reported while compiling the source code of a program. Each level is essentially 
a subset of the four types of conflicts defined above. Predefined levels can easily be 
defined for naive users: 

• Complete: Redundancy, Shadowing, Specialization, and Conflict 
15 • Errors only: Redundancy, Shadowing, and Conflict 

• Conflicts only: Redundancy and Conflict. This option is particularly useful in a 
system where individual policies are integrated in such a way that a specific 
policy always has priority over a (otherwise conflicting) general policy. 

20 Additionally, the database containing the previously detected conflicts can be 

turned off or be reset. This enables end-users to get a complete list of conflicts for a 
particular level of sensitivity. 



In the previous examples of suggestions, all underlined actions (e.g. set 
25 priority , disable ) are in fact hyperlinks constituting URLs with appropriate addresses 
and arguments that request from the policy server that the modifications selected by 
the user (i.e. clicked on) be executed. This automation level avoids the need to have 
the end-user modify the policies manually (and potentially make mistakes along the 
way). The conflict explanations also have hyperlinks to the policies involved, hence 
30 they can at any time be edited. 
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Each detected conflict tagged as "tolerated" is put in a database so it will no 
longer be reported. FIAT natively supports a database of previously found 
incoherences, and hence it can be used directly to avoid reporting known and tolerable 
conflicts. 

5 

It will be noted that the conflict resolution chosen by a user is based on local 
priorities and local activation of policies, and hence is independent from that of other 
users. Such personalized policy conflict resolution enables the same conflict to be 
addressed in different ways by different users, which is a major improvement over 
10 conventional telephony systems. 

Once the incoherences have been removed and the individual policies (CPL 
branches) ordered according to the priorities desired by the user, the individual policies 
may be integrated into a single CPL script according to the following recursive 
procedure: 

15 

integrate ( set_of _branches ) : - 

outputBranch (f irst_branch_of (set_of_branch.es) ) 
remove_first_branch_of ( set_of_branches) 
if not (empty (set_qf_branches) ) then 
20 open_otherwise 

integrate (set_of_branches) 
close_otherwise 
endif 

25 A more advanced procedure can also prioritize the policies in a way that 

removes all shadowing conflicts automatically, before the integration. Such an 
integration would implement the naive view that specialized policies always have 
priority over (conflicting) general policies, at the cost of less flexibility: 

30 removeShadowingAndlntegrate (set_of_branches) 

detectConf licts (set_of_branches, Conf lictList ) 
foreach conflict in (Conf lictList) { 
if type (conf lict) = shadowing then 

% Adjust the priorities in set_of_branches 
35 givePriorityTo (specializedPolicy (conf lict) , set_of_branches) 

endif 

} 

integrate (set_of_branches) 

40 While the embodiments discussed herein are directed to particular 

implementations of the present invention, it will be apparent that variations and 
modifications to these embodiments are within the scope of the invention as defined 
solely by the claims appended hereto. For example, whereas the embodiment set forth 
herein illustrates how Web interfaces (running on personal computers, PDAs, mobile 

45 phones, phones with HTML browsers, etc.) can be used to manage personal policies, 
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as suggested above, voice-activated interfaces can also be used. Existing voice 
interfaces provide audio menus and speech-recognition capabilities, thereby enabling 
the user to manage policies through his/her phone (wired or wireless) at any time and 
anywhere. To support voice, the Web server 7 needs to be coupled to a voice server 
5 and to generate the interface in a language such as VXML (Voice XML) instead of (or 
in addition to) the conventional HTML used for Web interfaces. 

The embodiment of the invention set forth above is directed to the situation 
where one end-user has control over all of his/her call processing policies. However, in 

10 an enterprise, there could be several layers of policies involved. For instance enterprise 
policies may be imposed on all employees (e.g. no outgoing calls to 1-976 numbers, 
also known as dirty lines), and group policies maybe applicable to a group of 
individuals (e.g. no long-distance calls, obligation to answer calls from the group 
manager (no voice mail), etc.). Personal policies defined by the end-user may 

15 obviously conflict with group and enterprise policies. 



In this context, conflicts are detected in the same way as discussed above in 
connection with personal policies only. A sorted list of policies is produced out of the 
combination of enterprise, group, and personal policies. A typical priority scheme for 

20 these layers would be 1 -enterprise, 2-group, and 3-personal, but more fine-grained 
arrangements may be supported. For instance, group policies may be split into two 
sets, the first with a priority higher than personal policies (mandatory), and the second 
with lower priority (can be overridden by personal policies). The analysis mechanism 
takes such scheme into consideration when reporting the conflicts (e.g. do not report 

25 conflicts between personal policies and group policies of lower priority). 

End-users would not have any means to modify group or enterprise policies, 
only their personal policies in such an enterprise application. Group and enterprise 
policies would be managed separately by designated administrators with sufficient 
30 access privileges. 
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Other variations and modifications will occur to those of skill in the art. All 
such variations and modifications are considered to be within the sphere and scope of 
the present invention. 
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We claim: 

1 . A method of user policy management in a communication system, comprising: 
receiving user-entered policies in a user-understandable representation capable 

of translation into a formal executable language; 
5 translating said policies from said user-understandable representation into an 

executable feature language capable of execution by said communication system; 

translating said policies from said executable feature language into a policy 
language and detecting common feature interaction errors between said policies; 

analyzing said feature specification errors to identify errors that are common to 
10 naive users; 

reporting said errors that are common to the user in said user-understandable 
representation; 

providing the user with a recommendation for correction of said feature 
interaction errors and re-integration of said policies in said executable feature 
15 language; and. 

uploading said policies for execution by said communication system. 

2. The method of claim 1, wherein said user-understandable representation is a 
Web browser interface. 

20 

3. The method of claim 1, wherein said executable feature language is Call 
Processing Language (CPL). 

4. The method of claim 1, wherein said policy language is Feature Interaction 
25 Analysis Tool (FIAT). 

5. The method of claim 1, wherein said step of receiving user-entered policies in 
said user-understandable representation further comprises receiving user-entered 
operations on said policies, including: 



30 



Create: for creating and activating a new policy; 
Modify: for modifying a selected policy; 
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Delete: for deleting a selected policy; 
Duplicate: for making a copy of a selected policy; 
Deactivate: for deactivating a selected policy; 
Activate: for activating a selected inactive policy; . 
5 Set Priority: for setting priority of a selected policy to one of either an absolute priority 
or a relative priority; 

Validate: for detecting and reporting conflicts among active ones of said policies; 
Approve: for approving and enabling selected policies for execution. 

10 6. The method of claim 1 , wherein each said policy includes: 
a name for use as a unique identifier; 
a priority, expressed as a numerical value; 

an operation, for application to a call within said communication system; 
a precondition, based on characteristics of a caller or callee, whereby said policy is 
15 general in the event that the precondition is a dom ain of values, and is specialized in 
the event that the precondition relates to particular values; 
a target, for said operation; 

an optional list of exceptions to said precondition in the event that that said policy is 
general, and 

20 a time constraint, during which the policy is active. 

7. The method of claim 6, wherein individual ones of said policies are translated 
into said executable feature language as scripts representing individual branches of a 
decision tree, with explicit priorities allocated among said branches. 

25 

8. The method of claim 7, wherein said priorities are allocated by numerically 
naming the individual branches. 

9. The method of claim 8, wherein said step of translating said policies from said 
30 executable feature language into said policy language further comprises visiting 
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successive ones of said branches downwardly and producing corresponding rules, 
using the following mapping: 







Name 


Rule name 


Priority 


Rule number 


Operation 


Rule result 


Precondition 


Rule triggering event 


Target 


Rule result 


Exceptions 


Rule constraint 


Time constraints 


Rule precondition 



5 10. The method of clam 9, wherein said step of analyzing said feature specification 
errors to identify errors that are common to naive users further includes determining 
whether each said policy is general or specialized and then comparing relative 
priorities of said policies. 

10 11. The method of claim 1 0, wherein said step of reporting said errors further 
includes identifying a category of incoherence, assigning a role of each policy in the 
occurrences of said errors, and providing an example of possible misbehaviour 
resulting from said interaction. 

15 12. The method of claim 11, wherein said errors that are common to naive users 
and are reported in said reporting step include: 

Redundancy: whereby two general policies are active; 

Shadowing: whereby a general policy overrides a specific policy such that the specific 
20 policy can never be triggered; 

Specialization : whereby a specific policy is selected over a general policy of lower 
priority; and 

Conflict: whereby two policies have overlapping preconditions but with different 
resulting actions. 



9 
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13. The method of claim 12, wherein said Redundancy error includes a Conflict 
with Redundancy error whereby a general policy and an exception for the other general 
policy lead to different resulting actions. 



5 14. The method of claim 13, wherein said step of providing the user with a 

recommendation for correction of said feature interaction errors includes the following 
suggestions: 

edit a policy; 

disable a policy; 

10 set the priority of a first policy above or below the priority of a second policy; 

add an exception to a general rule; 
tolerate the interaction and no longer report it. 
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ABSTRACT 



A method and apparatus are set forth for defining and validating feature 
policies in an execution system, such as a communication system. The method 
5 includes entering user policies described in a straightforward manner (e.g. using a Web 
browser and user-understandable language) in such a way that they can be translated 
into a formal executable language. The user policies are then translated into an 
executable feature language such as the IETF's CPL. The user is then either compelled 
or provided with an option to validate the overall feature set before it is uploaded to 

10 the execution system. If validation is selected, the features are translated from CPL 

into another format, such as FIAT, from which it is possible to detect common feature 
specification errors. The FIAT detected errors are then analyzed in a manner that is 
aware of the expectations and common errors of naive users, and interpreted to 
determine possible errors as errors that are common to naive users. These errors are 

15 reported to the user (e.g. via the Web interface) in terms that are understandable to 
naive users and compatible with how the policies were originally described. The user 
is provided with options to either accept the interactions as they are, repair them 
manually or to accept a recommendation of an automatic correction. Unlike 
conventional systems, where feature interactions are solved in the same way for all 

20 users, the selected resolution is personalized in the present invention to satisfy the end- 
user's intentions, independently of how others solve similar conflicts. The features are 
uploaded to the execution system. 
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